Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/linters/.gitleaks.toml:
- Around line 3-7: Replace the deprecated single-table header [allowlist] with
the array-of-tables header [[allowlists]] and move the existing keys
(description and paths) under that new table so the file uses the modern
gitleaks syntax; specifically, change the block beginning with [allowlist] to
start with [[allowlists]] and keep the description and paths array (including
the '''tests/support/data/.*\.php''' entry) unchanged so semantics are
preserved.

In @.prettierrc.json:
- Around line 9-20: The patterns in the "files" array currently use root-level
globs (e.g., "*.js", "*.ts", "*.vue") which won't match nested files; update
each pattern in that array to a recursive glob (replace "*.ext" with "**/*.ext")
so Prettier overrides apply to files in subdirectories (e.g., change "*.js" →
"**/*.js", "*.ts" → "**/*.ts", etc.).

In `@CHANGELOG.md`:
- Around line 8-12: Update the 0.2.0 changelog entry to explicitly mark the
change as breaking: modify the "## 0.2.0 Under development" section (the 0.2.0
entry) to replace or augment the current "- feat: convert into
`yii2-extensions/scaffold` provider..." line with a "- BREAKING CHANGE: ..."
prefix and add a short migration note explaining what consumers must change
(e.g., provider name change, config/key paths, or any renamed classes/APIs) so
users can follow upgrade steps; ensure the new text references the same 0.2.0
heading and mentions the concrete migration action(s) required.

In `@docs/installation.md`:
- Around line 24-26: The manual composer example places
"php-forge/coding-standard" under "require" but the earlier instruction uses dev
install; change the JSON key in the example from "require" to "require-dev" so
the package appears as a dev dependency (i.e., move "php-forge/coding-standard":
"^0.2" under "require-dev") to keep the docs consistent and prevent production
installs.

In `@rector.php`:
- Line 8: Add a clear comment in rector.php next to the import call
($rectorConfig->import(... 'rector-83.php')) instructing consumers to replace
that import with the version-specific file matching their project's PHP
constraint in composer.json; then update docblock examples in src/rector-81.php,
src/rector-82.php, src/rector-83.php and src/rector-84.php so they reference the
correct src/ paths (not config/) and ensure src/rector-82.php fixes the
erroneous import of rector-81.php to import the correct rector-82.php file and
any mismatched Set/Level references.

In `@src/ecs-81.php`:
- Around line 15-18: The example require path in src/ecs-81.php is pointing to
vendor/php-forge/coding-standard/config/ecs-81.php which doesn't exist; update
the require to reference the installed location under src (e.g.
vendor/php-forge/coding-standard/src/ecs-81.php) so the $builder = require ...
line resolves correctly (same fix applied as in src/ecs-84.php).

In `@src/ecs-83.php`:
- Around line 15-18: Update the require path used to load the ECS config in
src/ecs-83.php so it points to the package's src location rather than config;
change the string passed to the require for the $builder assignment (the line
with $builder = require ...) to
'/vendor/php-forge/coding-standard/src/ecs-83.php' (matching how src/ecs-81.php
and src/ecs-84.php reference the package) so the docblock/example uses the
correct installed path.

In `@src/ecs-84.php`:
- Around line 15-18: The example require path in the docblock is incorrect and
points to config/ecs-84.php which doesn't exist; update the require invocation
that assigns $builder (the line using require __DIR__ .
'/vendor/php-forge/coding-standard/config/ecs-84.php') to reference the
installed location under src (e.g. require __DIR__ .
'/vendor/php-forge/coding-standard/src/ecs-84.php') so the $builder variable is
loaded correctly and the subsequent call to $builder->withPaths([...]) works.

In `@src/rector-81.php`:
- Around line 21-23: Update the example import path in the docblock: the example
using $rectorConfig->import(__DIR__ .
'/vendor/php-forge/coding-standard/config/rector-81.php') is outdated after
centralizing files under src/; change it to point to the new location (e.g.
$rectorConfig->import(__DIR__ .
'/vendor/php-forge/coding-standard/src/rector-81.php') or the exact new path
where rector-81.php now lives) so the example reflects the relocated file in
rector-81.php.

In `@src/rector-82.php`:
- Around line 21-23: The import in the anonymous config function calls the wrong
wrapper file: update the string passed to $rectorConfig->import (currently
referencing 'rector-81.php') to reference the 8.2 wrapper ('rector-82.php') so
the config uses the correct Rector 8.2 rules; ensure the $rectorConfig->import
call now points to 'vendor/php-forge/coding-standard/config/rector-82.php'.

In `@src/rector-83.php`:
- Around line 30-35: The sets call is redundant: remove the explicit
SetList::PHP_83 entry from the $rectorConfig->sets([...]) call so only
LevelSetList::UP_TO_PHP_83 remains; locate the $rectorConfig->sets invocation
(currently listing LevelSetList::UP_TO_PHP_83 and SetList::PHP_83) and delete
the SetList::PHP_83 element, leaving a single LevelSetList::UP_TO_PHP_83 entry.
- Around line 21-24: The docblock example uses the wrong package path: update
the Rector config import in the anonymous return function so the call to
$rectorConfig->import(...) points to
'/vendor/php-forge/coding-standard/src/rector-83.php' (not
'/vendor/.../config/...'), i.e. edit the import argument inside the static
function where $rectorConfig->import is invoked to reference the src directory
so consumers won't get a fatal missing-file error.